Techniques for Securing Transactions With Identity Verification and Verifiable Claims

John Tolbert:
Hello, and welcome to our webinar today. Our topic is techniques for securing transactions with identity verification and verifiable claims. And we're joined today by Mike Engle, the chief strategy officer of 1Kosmos. So a little bit about our upcoming events. As you know, KuppingerCole does a lot of events, including virtual events these days. Next up, we have Customer Technology World, CusTech, that starts the week of October 20th, and we also have a parallel event, the KCLive Tools Choice about privacy and consent management. And then after that, we have our cybersecurity leadership summit, which is both virtual and has an on-premise component too in November. So we hope you can join us for those. A little bit about the webinar itself here. We control the audio. There's no need to mute or unmute yourself. We are recording the webcast, and both the webcast and the slides should be available within a day or so. And we are saving time at the end for questions and answers. And if you look at the... Go to webinar control panel, there's a blank for entering questions. You can type in questions at any time as we're going here.

So I'm John Tolbert, lead analyst. I'm going to start off by talking about identity fabric framework, some fraud trends and mitigation techniques, specifically identity vetting, and decentralized IDs and how we eventually want to use this to move to all multi-factor and password-less authentication and still get high identity assurance. Then I'll turn it over to Mike, and then we'll go for questions and answers. So we'll start off by looking at identity fabrics for consumer identity specifically. So what is an identity fabric? This is our concept for... Really, it's an architecture. It's how do you deploy an architecture that can serve very modern needs of identity management in the workplace and then also for consumers. And we found that we definitely see trends that IAM vendors, CIAM vendors, are really turning their products into identity API platforms as the delivery model. And this means everything essentially gets instantiated as a microservice that can be both managed by, in many cases, APIs, but then also third-party applications have the ability to pull information that they may need about end-user identity, consumer identity into their applications and use that as well.

And there are several advantages, and we'll talk about those in, in just a minute. Ultimately, it reduces complexity for the team that administers it by building this set of technologies and being able to access it via API. We contrast this with how have typically we've done IAM management for the last 20 years. Years ago, you'd buy an identity management suite. It would either come with, or you'd build up, a silo of user data, typically an LDAP active directory or something like that. It'd be managed by admin users just using a GUI, not necessarily as extensible as many enterprises needed it to be. For a long time, it was difficult to integrate with other applications, because there really weren't standards to support it. The data models were inflexible. You were limited to LDAP. Couldn't really evolve to meet all the needs that businesses had, not only for business to employ business-to-business use cases, but especially for consumer use cases.

So as I was mentioning about identity API platforms, the idea behind this is let's break all the different functions into specific services. So let's have authentication functions, authorization functions, identity proofing and vetting services. And then this allows enterprises to add functionality or upgrade functionality discretely. You can add authenticators more easily if you don't have to up upgrade your entire IAM system. And then also, many enterprises found that they wanted to use data stores that were different than LDAP. We find MongoDB and NoSQL databases are sometimes commonly used for consumer-facing applications, and these platforms can more easily communicate with CIAM and IAM solutions, as well as line-of-business applications. And it's really made more for a developer point of view than just an administrator who uses a GUI.

So let's look at the structure of this. They're service-oriented, meaning you've got your application, but you also have the identity API layer, and then the platform, which is the backend. And more and more, we see enterprises using cloud-delivered services for this. Microservices and containers. This is for agile delivery, DevOps methodology. Again, if you have an authentication microservice, it's much easier to add functionality to that rather than having to replace a whole IAM stack, same thing with authorization. There are discreet authorization services now, where you can add protocol functionality, again, without having to make major changes to other aspects of your IAM deployment.

And then it's ultimately about access to identity information and data, but we need to be able to provide access to these things very securely. It's good to not have your identity data spread around in different end user or line-of-business applications, but to be able to centralize that and then control access to the identity data as needed. So this chart shows... It's kind of a busy chart, but I think there are a couple of things that we want to express about what identity fabric means from a consumer identity point of view. Looking at the three big blocks in the middle, we've got capabilities, including things like adaptive authentication, credential intelligence, and things like that that we'll mention later that need to be brought to life as services. And again, here, this is where we have things like an authentication service, a fraud risk intelligence service, maybe augmented by things like device identity and intelligence services.

And how that translates into your actual security and identity architecture, they're exposed via APIs, but built as microservices. And the purpose for this is not only to make it easier to bring on new, totally digital services to support digital transformation, but also have a layer that can communicate with legacy IAM and then other line-of-business applications that may not necessarily support all the latest protocols and standards. So now, let's talk a little bit about decentralized IDs. So I think we've heard about BYOD, bring your own device, for quite a while now. The BYOID is bring your own identity. And obviously we're doing that in the consumer world for quite some time, where consumers are used to being able to take their preferred ID from a preferred identity provider and use that in different locations all around the web. With things like BYOD in the consumer space, if you couple that maybe with the notion of self-sovereign identity that might be backed up by blockchain in some cases, then we can also add attributes as necessary from authoritative sources.

And again, we can talk about that just a bit more in a minute too. You may want to enrich that with government-provided identity attributes, or employer provided, or school provided. And then these can be used to help satisfy use cases like know your customer and anti-money laundering. And believe it or not, we see cases where some companies might enable employees to use other third-party credentials, which can then be sort of enriched with additional attribute information. And this has been going on for a while too in the partner space, if you think about federated authentication, federated authorization. If you're in a supply chain relationship with contractors, you will utilize the partner's identity schemes, and trust their authentication. So we have this notion of... Bring your own identity has been in place for a while, and it's actually being expanded.

And then lastly here on the chart, we've got devices and things. Devices, mostly we're thinking about mobile phones, tablets, things that may have an identity of their own and may be associated with a particular user identity, whether it's employee or consumer. But that ownership may change over time, so it's important to be able to express that relationship. Same thing with IoT devices or things. They can have a device identity, in many cases, and they may be linked to particular human user IDs as well. So when we look at decentralized identity, we first look at the user's identity credential, and then look at potential cases where it can be enriched by additional attributes, for example, a bank. In the Nordic region, the bank ID is a fairly well-trusted ID that can not only be enriched by the bank, but many service providers actually accept bank IDs. And these in turn can also be enriched by other attribute sources too, let's say, a health provider. It's possible to use things like zero-knowledge proofs such that a health provider could provide a proof of age without actually giving away things like birth date.

Same with government-issued IDs. Government-issued IDs, as we'll see later too, can be the basis for credentials, can be used to verify identity. And then there are various kinds of attributes that need to enter the ecosystem, let's say, address verification, for example. So that's a use for government-issued ID credentials. Employer. There are use cases where proof of employment is needed, maybe for getting a bank loan or something like that, so having decentralized IDs with the ability to add that kind of attribute information is very useful. And then same thing with autos insurers. We see use cases where maybe you need proof from the Department of Motor Vehicles, or some other government agency passed on to an auto insurer, and then vice versa. The auto insurer can provide information about driving record as far as they know. These things are useful because fraud happens, as we all know, and fraud is increasing, unfortunately.

It's estimated that it'll hit about $6 trillion worth of drain off the global economy next year. And really, just about every industry is as a target. We always commonly think about banks or financial institutions and retail, but telecom is often hard hit, healthcare. Healthcare can be kind of a rich source of records. Travel and hospitality, not as much anymore, but G2C, government to citizen, that's been hard hit in the last few months related to COVID and various scams of fraudulent actors trying to get different kinds of payments from citizens.

So we'll look at a couple of major fraud types. On the one hand, we've got new account fraud, synthetic fraud, sometimes called account opening fraud, and then account takeover fraud. We'll dive into those here. We'll start with account takeover. How do bad actors get that? Well, phishing is probably the most prevalent method. Send a email or text. Or even vishing, voice phishing, is becoming increasingly common. Again, the idea is steal the credentials. It can happen through drive-by downloads or fake websites that are designed to harvest credentials, keyloggers, rootkits. Sometimes, spyware can get identity information out of cookies. Credential stuffing attacks, that's using information, and compromised credentials from the dark web, and then blasting that out against lots of other websites to see what they might get into. And that works in cases where users have reused passwords. And then there's the old brute force password guessing method.

The idea behind it is take the username, passwords that have been recovered from breach password dumps on the dark web, and they're used for financial fraud, just like you might expect. Banks, financial accounts, 401(k)s. Anything that's convertible into money is often a target. Rewards programs, even. And we think the best mitigation against this is multi-factor authentication, risk adaptive authentication, powered by fraud and threat intelligence, doing things like identity vetting. And we always tell people: Don't reuse passwords, and better yet, don't use knowledge-based authentication for account recovery. New account fraud happens when fraudulent actors go out and grab PII and use it to build accounts that are not associated with the actual individual, and sources of this information can be healthcare companies, government agencies, school records. And they too are used for financial fraud, but they're to create mule accounts to move money around, get credit cards.

Why would they do that? It takes more effort, but it's harder to detect, and simply stealing and using a credit card number once or twice before it gets canceled. The major mitigations here are bot intel and management. A lot of the activity is perpetrated by bots. Identity vetting, as we'll get into. And then in some cases, users can request credit freezes. So the main fraud reduction techniques, as I see it, are identity proofing and vetting, credential intelligence, device intelligence. Where's your phone or other device been? Is it healthy? User behavioral analysis. That's looking at: Is the current transaction request sort of in the same spirit as other requests in the past? Behavioral or passive biometrics. That's maybe using swipe analysis, or how users use their keyboards.

Then bot intelligence and management is being able to determine what activity against your website is real, what's bought, and then how do you want to handle that. I'm only really going to talk about identity proofing here today, but this is using government-issued credentials generally to validate a person against these authoritative documents. It's often driver's license or passport, as you might expect. And just to reiterate, these can help a lot with complying with anti-money laundering laws and getting information for know your customer regulations. And then there's also value if properly consented to know your customer initiatives in terms of doing personalized marketing. The main driver here is to increase identity assurance in not only consumer use cases, but even in B2E or B2B business relationships as well.

And finally, just wanted to talk a little bit here about risk adaptive and the move to password-less authentication, again for not only high identity assurance, but high authentication assurance. So risk adaptive authentication, we mean doing a risk analysis upon every transaction. And this is a combination of user device, and then an environmental context. So what attributes can you pull about the user, whether it's from LDAP or a behavioral analysis? A bit about the device, where the request is originating. What do we know about it? Has it been fingerprinted? What's the history? Is it healthy? Does it have anti-malware installed? OS patch level? And then looking at it in context of the environment. Where's the request coming from, geolocation? When? What network? Do we think it's a bot activity? Do we think this has been influenced by malware in any way? This kind of decision needs to take place ideally with every transaction.

And again, the goal here is to provide a password-less authentication experience, especially for consumers, because you want to make the user journey as easy as possible, but also for employees and B2B partners too. And we do this by using things like MFA, get away from the password, use biometrics, behavioral biometrics, things that are easy for people to use that don't require them to memorize passwords, which could also be phished or stolen, and then using adaptive authentication to really do this sort of continuously in the background. And two ways forward with this. This is now pretty well supported in the latest versions of Windows. And then also, FIDO2 is a good standard for password-less authentication. It brings together some of the best things about the earlier versions of FIDO UAF and U2F. And then also with the web, often specification allows access to web resources, and is pretty well supported. And we increasingly see vendors moving toward FIDO2 as a standard to promote password-less authentication. And with that, I'd like to turn it over to Mike.

Mike Engle:
I appreciate it. So once again, everybody, my name is Mike Engle. I run strategy and business development for 1Kosmos, and I'm going to touch on a couple of the identity concepts that John brought up in his slide, specifically decentralized identifiers and identity proofing, and what we can do with them from a password-less perspective. So John touched on a bit on the challenges side and the fraud and so forth, and I'm going to get pretty deep into two specific sources of these frauds. And the number one item that he had called out was phishing, specifically phishing which leads to business email compromise, lead to 60% of all breaches. And this is in stat after stat from major research from the likes of Verizon, IBM, Barracuda, et cetera. And what's changing, of course, is COVID over the past six months. Everybody's working remotely, and it increases the attack surfaces dramatically.

And business email compromise is a very targeted type. And so if someone gains access to a trusted email via phishing... I target 1,000 corporate users with a spray and pray technique, I get five people to bite. I now have five trusted accounts to do my spear phishing, resulting in business email compromise. And the stats on this are really staggering. I'm not one to throw stats around, but these are really significant. There's been a 700% increase in phishing and business email compromise attacks since COVID. And I know on my personal device, I'm getting fake UPS and election-type texts trying to get me to click on links all the time. I'm sure you guys are too. And the impact of this goes beyond just potential data loss and somebody getting inside, because now IT professionals are always walking a tightrope between two activities.

We have to defend against breaches, and then we also have to support top-line activities. So now we're spending more time defending, and less time supporting the business, and that has taken quite its toll on our time, effort, et cetera, along with everything else that we're struggling with today. We're being pulled in many different directions. And phishing isn't the only vector. Just take a look over any of your coworkers' shoulders on the next Zoom that you're doing, and you'll see, I'm sure, an improperly secured home router with some password that the user selected out of their brain. And then the other side of the room, you have half a dozen cloud-enabled IoT devices, probably using the same password, and then you have half a dozen personal devices and social accounts for the employee. And we know humans are creatures of habit.

We all try to use different passwords, but we don't, even when it comes to corporate. So the other thing John mentioned is password reuse becomes a real challenge. So what's to stop somebody from using their Microsoft Live account or their Facebook account to come in and use that on the front layer of your VPN or your Citrix, or the front door into the environment? And you may put some MFA on top of that, which helps, and I'll touch on MFA in a minute. So the point of this is it's not just phishing, it's username and password exposure that are really exasperating the problem. So now, what if we could authenticate the user without usernames and passwords? So getting back to the header on this slide, what's the common theme across all these services? It's identity, and identity is not a username and password.

A username and password is hope that the user coming in is who they say they are. So we have to replace today's hope-based authentication with identity-based application. And here's one last way to think about this, and this slide is really a way for me to make a little bit of fun at our own expense. I've been in IT for 30 plus years, and in security for 20. So when we use usernames and passwords for authentication, it's what we here at 1Kosmos refer to as HBA, or hope-based authentication. So we ask our users to use a username and password to come into Windows or whatever banking, et cetera, and we hope that they can remember it. We hope that they've created a strong password. You make them change it every 75 days. Now you hope they don't get locked out. And then you'll sprinkle on some MFA, and you hope they can figure that out as well, don't lose their token, et cetera.

And then you hope the password was not stolen from a central database, and it wasn't man in the middle or socially engineered or phished as we brought up before. And I'll share a quote with you from James Cameron that really resonated with me when I heard it, and what helped us kind of coin this phrase. And it's relating to the balance we all have between risk aversion and risk taking, and you need to balance it. It's what we all do as security professionals. But what James said is, "Luck is not a factor, hope is not a strategy, and fear is not an option."

And this slide's one of those kind of logo vomit slides that tries to show all the cybersecurity players that exist in the identity space. And everybody in the audience knows this well. There's so many vendors in this space. It's hard to know which way is up or down when you talk to them. And the reality is over 50% of these companies exist due to the insecurity of using usernames and passwords to guess who's accessing our systems. So I'd like to call these companies, a lot of them, password mitigation companies, and they fall into a bunch of different categories that we're all familiar with. And John touched on a couple of these earlier. So of course you have the username and password, which is the root of the problem. But since that's not good enough, we make the passwords expire every two, three months, and we put some crazy complex character requirements into them.

And then we'll add some two-factor authentication, which includes email, SMS, one-time passwords. And then when two's not enough, we'll add more factors. We have MFA, and we have RBA for risk, we have KBA for knowledge-based. We now are implementing single sign-on. And then we have password managers, which put one big password around all your little passwords. And we're also using things like pins and keys. John mentioned FIDO, and I'll talk about that a little bit more, because that is definitely a step in the right direction. But all of this is to strengthen the username and password. So now that 2FA has gotten really popular, just about every cloud service is pushing this typically via SMS. Your Apple, everybody's going to 2FA. However, it's not the answer. We've already touched on the notion that adding layers on top of usernames and passwords just doesn't work.

It exasperates the user, and it's still very susceptible to phishing. And most notably, note how Jack Dorsey was hacked two months ago. The FBI is also warning that there's four specific types of 2FA theft attacks going on. They're on the rise. And these layers, they're tiring out our users, and they're not really helping that much. So it's time to get rid of the credential, which closes the vector 100% of the time if you do it right. And I'm not just talking about going password-less, I'm talking about going credential-less, getting rid of both usernames and passwords and external MFA systems, and migrating from HBA, hope-based authentication, to identity-based authentication. So now, we had our other slide. This looks familiar. And by now, you're all probably like, "Mike, enough about passwords. I get it. You're describing the water while I'm drowning in it."

So we've secured the network. We've secured many of our devices. We're protecting the data as well. And this final layer is to now, as John brought up very early his presentation, verify the identity and authenticate the user properly. Because all the security that we put on the networks and the systems is useless if we open the door for the wrong person. So what the technologies that John mentioned, specifically around identity proofing, decentralized identifiers, what they do is allow us to ask the question of your remote users: How do I know you really are who you say you are? And to do this, we need to introduce the concepts of identity verification and proofing to our IAM stack, and there's a couple ways to do it. So John touched on credentials. You can always ask your employee, new hire, or customers for a government-issued credential, or you can exchange their current username and password for a public-private key pair. And that's some of the principles that are coming out in the FIDO2 concepts.

So that principle of the public-private key pairs is what decentralized identifiers brings to the table for you. And when you think of public-private key pairs, you're probably thinking, "Oh God, not PKI, not smart cards," because they're a management nightmare. Well, decentralized identifiers solve a lot of those usability challenges. So decentralized identifiers will bring three benefits and solve three key issues for your IAM stack. The first is: Who's at the other end of a digital connection? So now, you can enroll and store digital identity, and more importantly, biometrics into an identity safe or wallet. And many times, the user doesn't even need to know that a identity safe is involved. They just go about doing things the way they do today. And there's identity proofing standards, specifically NIST 800-63-3, and has a whole framework which allows you to make sure that you have a strong remote identity at the other end of a connection.

The second is: How do you authenticate them now? So we've enrolled an identity. How do I authenticate them without passwords? So as I mentioned, DIDs provide public-private key pairs and introduce that along with biometrics instead of usernames and passwords. So this allows you to use identity-based authentication and not hope, which is what I've belabored on quite a bit. And as John also mentioned, FIDO uses similar mechanisms to replace passwords with public and private keys. However, FIDO doesn't have an identity component, and DIDs bring that to the table. So when you combine DIDs with FIDO principles, it really strengthens the story. And the third challenge that decentralized identifiers solve is: What credentials does this person have? And John had that one slide that showed education and health and so forth, and I'll give some real-world examples of those in a minute.

But now, you can assign and verify an industry or personal credential in a very safe and secure manner, and store it into the identity safe. And the best part of that is you don't have to present the original credential. You don't have to give somebody your diploma or some type of employer card, for example. So it's easy to see this kind of alphabet soup here on the right side of the screen and think that it's going to be very cumbersome to implement, but let's take a look at how we can turn identity and authentication a little bit upside down without introducing too much complexity.

So a key enabler towards embracing decentralized identifiers is that they can be used without requiring a whole lot of infrastructure changes. Really, all you're doing is pushing the key out into the user's hand, because the last thing you want to do is try to implement some heavy user interface or backend IT lift. So obviously, nothing in life is free. You do have to make some changes, but let's take a look at what little really needs to change. So this diagram here on the bottom is your typical IAM stack. And John's [inaudible 00:34:12] much more complex and detailed, but if you really boil it down, you have account management, authorization, these types of buckets here in the middle. And we're going to move the credential to the edge with the user. So the three components that are required to enable DIDs, decentralized identifiers, for customers or for your workforce employees, the first is a digital safe or wallet.

And this is typically embedded into an existing app, or you can be handed a new one, and I'll cover how frictionless this is in a minute. The second component is an identity gateway. And basically, this is either a cloud or an on-prem service. It bridges the user to the requesting application, and then it can also make API calls to verify identity information, either when they're enrolled or when risk calls for it. So when you put DIDs into workforce or customer IAM functions, your organization acts as the issuer and the verifier, if you're familiar with those terms. But what this means is that you don't have to wait for this futuristic network effect to come about to realize the benefits of decentralized identifiers today. The third piece of the puzzle are lightweight connectors or simple federated login changes. So this allows the DID to be translated into an existing username. For example, your DID would be translated into your Windows username and password behind the scenes without requiring any application re-architecting.

So if you put the DID in the hand of the user, there's a couple steps involved. First, we give the user an app or enable the DID functionality into their existing app via an SDK. And once the app is launched, the user's decentralized identifier, public and private keys are generated. And the key is stored in the enclave of the phone most times. There's a couple ways to do it. And next, we'll let the user enroll their existing account credentials. So for example, this is where they'll put in an AD username and password, or their current banking username or password with their banking app. So you kind of proof them based on their existing authentication mechanism. Behind the scenes, you're exchanging the credential for a key that mirrors smart card functionality without the need for a smart card reader. And then fourth step is we'll capture their biometrics.

So we will use, from 1Kosmos, what we call LiveID, where we use the camera with a liveness test which can't be spoofed. And then we can also turn on their device biometrics as well, your touch ID and your face ID, which have... They're very trusted and liked by the users, so you have a couple options. So the friction for the user is minimal. They're simply entering their existing username and password just like they do today, linking it to their biometrics. And this is the last time that they'll have to rely on hope to get into a system. And now that we've enrolled in identity, the employee or the customer will enjoy the same experience, no matter what type of service they're coming into. It can be a workstation, any webpage, even physical buildings for access control systems. So they'll simply scan a QR code or they'll get a push message, they'll authenticate with either device or advanced biometrics, LiveID, and then lastly, permission is granted.

So I'd like to give a real-world example of how one of our customers uses decentralized identifiers today to simplify the user experience coming into the systems and making life easier for the IT department, focusing on a doctor prescribing controlled substances here. So as you can imagine, it's a legal requirement for doctors to be verified before they can work with a system like Epic. And this is where strong identity proofing is done on first touch. Let's proof that physician and make sure they really are a physician. So instead of taking their documents, driver's license, passport, doctor's card, or whatever to the notary or to the home office, they'll scan their government-issued credentials with the app and validate it against backend sources in real time. And the security features of the documents are checked, and API calls are made to third-party sources of truth, like the federal issuing authority for a state or passports.

Then the physician's database is checked as well, so you can check: Does this physician card match John Smith's driver's license and passport? So in a matter of minutes, they're compliant with company onboarding policy. The next step is for general systems access. So they'll use device biometrics, touch ID, negating the need for username and password to get in the front door of the application. And the third requirement is for the doctor to be verified with MFA whenever they prescribe a controlled substance. So the legacy system had cumbersome external tokens as a second factor, username and password before that. Now, their identity is verified in real time as they authenticate in one step. And furthermore, because decentralized identifiers can have cryptographic capabilities with them, a digital signature can be stored on a distributed ledger. So now you've got an immutable audit trail, which is also required from a compliance perspective for most systems that companies like this deal with.

So we've covered identity-based authentication. We know how to get them in the door now, but DIDs can also extend their capabilities to cover verifiable credentials. So this is a W3C standard. John touched on them briefly, where he was showing that you could have certain credentials tied to an identity. Basically, it allows an organization to issue any type of qualification or other piece of information to somebody. So this isn't just "Is this person who he or she claims to be," which DIDs do very well, but, "Does this person really have a fine-grained identity entitlement?" So common credential types are education degrees. There's a number of efforts among universities and other educational institutions, where they're trying to create a digital diploma or a core certificate. And you as an employer will be able to get a copy of this digital certificate and verify it without seeing the original diploma. And then employers themselves can issue employment status.

So this has right to work-type use cases. And this is another way for organizations to trust who they're working with without having to do heavy federated authentication tying two active directories together, et cetera. So these certificates get tied back to the original identity. So imagine where your contractors could prove who they are, that they work for a consulting company, and link it back to their biometrics. There's no more swapping of usernames while somebody's brother fills in for them. And recently with COVID, the COVID credential has gotten a whole bunch of industry attention. So without a verifiable credential, travelers, just starting to maybe leave their houses now, are carrying around pieces of paper that said they had a PCR test yesterday. It's almost useless, incredibly easy to forge, and incredibly difficult to verify. And when vaccinations come out, there's going to be a need for a trusted digital attestation about immunity that can be used by employers, merchants, governments, airports, et cetera.

And this is a perfect use case. So day one, when these credentials come out, your organization can issue a go back to work certificate, and they can be verified at the front desk of the building without having to reveal health records or any other personal information. On day two, national organizations will plug in and the network effect will start to bring efficiencies across the globe. And this is happening at the World Economic Forum level. We're plugged into those efforts. And verifiable credentials follow all kinds of privacy principles around identity verification, such as zero-knowledge proof, so this is where the original document doesn't need to be seen by the requester. And they also protect the user's identity and personal data, and have very powerful mechanisms for sharing the credential revocation and renewal. All those kind of key-based applications are built into the standards as well.

So one last slide on a real-world verifiable credential in action. So the beauty of DID-based verifiable credentials is that the same platform that enrolls and authenticates can issue these credentials. So here's an example of a LinkedIn page with employment and education properties. We all see these every day. We never know if they're true. You guys didn't know that I actually went to Oxford. There's parts of LinkedIn that already allow the issuing of verifiable credentials to prove that an individual actually has a certain education certificate. So your organization can participate in this as an issuer or a verifier with minimal friction. And we're starting to see this come out. Microsoft's talking about it. Obviously they own LinkedIn, so we're very optimistic that this is going to be a big enabler. So with that, I'll hand it back over to John. Thank you everybody for listening, and I'll see you on the web.

John Tolbert:
So yeah, now we have some questions. The first question is: Are there standards for identity services? Yeah, there's quite a number of them, actually. Let's see. So some of the ones that we've talked about... We'll go way back. We'll talk about LDAP. That's a standard for directory access, lightweight directory access protocol. SAML, security assertion markup language, that's a way of representing authentication events between different domains. There's JWT, Jot, JSON Web Tokens. OAuth is sort of a federated authorization service, and OpenID Connect, which is a layer on top of that. And then we've talked about FIDO. I think of it as... It's an identity standard. It's a way of specifically being able to translate authentication events between different domains. So yeah, there's a lot of different identity standards, and happy to discuss that in more detail offline, and can refer you to some other publications that we have about that. Anything you'd like to add on the standards, Mike?

Mike Engle:
Yeah, absolutely. I mentioned one standard, the NIST federal guidelines for identity proofing. It's Special Publication 800-63-3, and that covers how you... There's three levels. They call it IAL1, 2, and 3, and 3 is a very strong identity. It's kind of the identity you need to move money at a bank. So for banking, they have KYC and anti-money laundering. They need a level 3 identity, which is typically two forms of government identity, proof that you live at the address you live at, et cetera. So 800-63-3 is one. You mentioned FIDO and WebAuthn, which are emerging and kind of getting a lot of attention. And the two concepts of DID and verifiable credentials are from the W3C governing body, so they kind of tie everything together as well. But the other ones you hit on. I think that really rounds it out.

John Tolbert:
Then there are a couple of questions about the slides and presentation themselves. Yeah, they'll be available probably by tomorrow. We'll have them uploaded on the website. And then another question: Any comment on SIOP? Some reason, not getting the context to that. Yeah, if you want to follow up with more information on that, we'll address it here in the next couple of minutes. Next question, I think this one's pretty good: Do companies really trust document scanning for the onboarding of employees and contractors? Yeah. I think my perspective on this, and then I'll let you have a go at it, Mike...

There are enrollment attacks, I guess we call them, for both IRL and real life kinds of situations, where somebody might go to a bank and present a driver's license that's forged or something like that. So there's always a risk, but I think what these mobile onboarding document scanning does is sort of enable business, especially today because of things like COVID, when it hasn't really been that easy for the last six months for people to do things in person... I think there are definitely technical means for reducing that risk that are just as good in many cases as some of the in-person kinds of presentation and document creation and verification. What's your take on that, Mike?

Mike Engle:
Yeah, we've been doing credential scanning for quite some time, driver's license, passport. It is difficult, because... Take driver's license. There's 50 different formats in the US, and every country has its own format. And we rely on partners like Keesing and Mitek to augment what we do and give us a global footprint there. So it's getting stronger. On the passport side, we have the chip that we can read off the passport, so that's very difficult to forge. I would say nearly impossible for most actors. And what that does is it's signed by the issuing authority, and it gives you a high quality photo. The other thing is the alternative to doing it on a phone is some person sitting at a desk at the branch of a bank or the auto dealer is trying to do it themselves.

When you can apply consistent technology and then possibly go deeper into three, four, five different sources of truth, it really strengthens your chance to know that this person is who they say they are. As all the proofing government documents mature... The states are going digital. There's two states issuing digital driver's licenses now. There'd be less opportunity for forgery as that matures as well. It's in the early stages. It's being matured very quickly, and we like where it is now, because it's better than the alternatives that people have to present: scanning, faxing, putting a copy in the filing cabinet.

John Tolbert:
Okay, let's see. Next question, a couple of follow-ups on the... Let me read through this. More about identity services, take it up a notch. What about API coding level authentication, authorization, create and manage something to hide protocol details? Yeah. I think that there are... Well, let's think about OAuth and OIDC. I think there are some profiles there, and I think that relates to the next question about SIOP, the self-issued... Yeah, there are profiles at OpenID that I think can help within that realm, which is probably the largest percentage of protocols that are in use today in this area.

But I think the there's actually additional room for some standardization at the API level. And I think that's a good question, because that brings out the point that if you're using different kinds of products, even different services, you want to be able to abstract the details of how an API is implemented away from the calling application. So I think the question is a good one, because it, to me I believe, shows that there is additional need for standardization, particularly around how to address APIs for the individual services in an identity fabric. Do you have any comment on that, Mike?

Mike Engle:
No. It really does come down to your provider of identity proofing and authentication being flexible, standards-based, loosely coupled so you're not locking yourself in. And for example, why can't an API that's relying on a token, a username, be able to go back out and ask the user, interact with that system, and say, "I need a higher level of assurance. I need that NIST IAL2 from this user," and kick off a workflow to be able to do that? So it's right in line with the concept of the identity fabric that you had on that rather busy slide. I think those pieces need to fit in there. And it ties into the APIs that you're mentioning.

John Tolbert:
The next is a clarification about SIOP. It's the SIOP extension of OIDC, where DIDs can cause OAuth tokens to be self-generated. I haven't delved into that too much. Have you looked at that, Mike, in context of DIDs?

Mike Engle:
No, I haven't, just being honest. We use OIDC for authentication, and typically this is the type of thing that our CTO Rohan Pinto would get deep into the weeds on, I think. So might have to take that one offline, and I have a little bit of education to do on that one. Another acronym for us to add to the mix. I like it.

John Tolbert:
Well, the OIDC space is very, very active right now, and there are lots of profiles. That's opportunities there too, because of the potential complexity with keeping up with protocol changes. And I will say, one of the things that I've really liked about what OpenID is doing is offering certifications for products in that space that support different parts of that. I think it's really necessary in the standards world today. Kind of going by back to the other question about standards, I think certification for products is increasingly important. Because it's one thing to say, "I support the standard," but then, well, what part of that standard do you support? And are you keeping up with it? Because even though the standards writing process can take a while, there are enough of them that there are substantive changes that come out from year to year that require vendors to keep up to date with that.

So merely saying that you support X standard without some sort of really a third-party demonstration and certification of that, I think, is very important. Next question is: Are there any enterprise business problems that decentralized identity is a good solution for? The well known use cases seem to fall into B2C or G2C. I typically like to use B2C and G2C use cases as examples. Mike, you started to hit on some of these as well. Would you want to go into any more detail on sort of the use cases there for enterprise?

Mike Engle:
Yeah. Actually, if you'll let me share a screen, I've got a picture worth a thousand words on this one. And that's a key enabler. The benefits of decentralized identifiers and giving the user the key can really simplify the whole stack that you have. So if you move away from usernames and passwords in the enterprise, there's a couple things that happen. First is you are fixing the user experience. So usernames, passwords, changing, forgetting, et cetera are one of the biggest detractors for your Net Promoter Scores, if you check your users on the user experience of their internal systems. So I mentioned the binding, getting their active directory username and password, and then using that internally. We will apply that seamless password-less experience to Windows as they sit down for the first time in their chair, remote access VPN.

And then from there, let it handoff into Okta or Ping, et cetera, so you don't even need a username and password to get into those systems. So it's not just for customers. In fact, some of the quickest benefit of this technology is for workforce, because you can measure the ROI at your help desk level in two months. You had 200,000 help desk calls in 2019, X number per month. Just measure it. Once you get rid of usernames and passwords, that number will come down. And the analysts all out there put the cost of a password at between $25 and $70, depending on the cost of the user that's getting locked out. So we're seeing this being the first place that DIDs are being used today, is in the workforce. And again, FIDO, which is all over, is based on the concepts of the DID. It just doesn't bring any identity to the solution. So we're very optimistic that workforce is going to be a big enabler for DIDs as well.

John Tolbert:
Yeah. There's another great question here. Any comment about how the UIX needed to affect fine grain end-user consent? Yeah, I think that's a fantastic point. And actually, we're going to address privacy and consent in this KCLive Tools Choice event coming up on October 20th. We've got a leadership compass and additional research documents on privacy and consent management platforms, and how to put that into place. I mean, depending on jurisdiction, there are differing needs for collecting end-user consent, particularly for the use of specific attributes.

GDPR and now CCPA are getting a lot of attention, but those are just two of many different privacy regulations that even though they may be similar in some ways, will probably wind up having different implementations. So I think that's a whole other subject that we can start to address in the KCLive Tools Choice, and happy to discuss that with you offline, too. One more question, and I'll drop this one on you, Mike. It's about: What's the performance overhead? Because I'm assuming it's talking about the DID use cases and attribute enrichment that you were looking at. Can you say anything about how this performs?

Mike Engle:
Yeah, it's a very lightweight exchange. So take the example of going to a banking website. First of all, the performance from the user experience is much better. Typing in 20-digit username and password, and going to fetch your MFA, out of band, whatever. That's probably a 10, 20 plus-second exercise. So then the user's doing it in two seconds. Scan a QR code or get a push message, touch ID, and they're in. And the backend, there's really no overhead, no more than there is pressing enter and verifying hashes. There's a very lightweight exchange, and typically these systems are designed to scale horizontally as well, if they're properly designed. So performance really isn't an issue, and it's pretty straightforward.

John Tolbert:
Well, great. That looks like the last question that came in, and we're at the top of the hour. So I want to thank you, Mike, for your time today and good information, and thanks to everyone who attended, and all the really, really good questions here today, too.

Mike Engle:
Great. Thank you, John. It's fun being here.

John Tolbert:
Great. Well, thanks everyone, and these slides and webcast should be up in the next day or so. And join us for our next event. Thank you. Have a good day.

Mike Engle:
Take care.